fix: skip an invalid camera instead of crashing the map - #160

What does this change?

camera is the gap #158 left behind - its README section named it: "the camera prop is not validated anywhere". It reached both SDKs unchecked, the way region did before #158. Both crash paths were reproduced against the real SDKs rather than assumed:

• MapKit raises an Objective-C NSInvalidArgumentException - "Invalid camera centerCoordinate" - from -[MKMapCamera _validate] inside -[MKMapView setCamera:] for a NaN, infinite or out-of-range center. Swift cannot catch it, so the check has to happen first.
• CameraPosition.Builder.tilt throws IllegalArgumentException for any pitch outside 0..90 - NaN and ordinary values such as 120 alike - which unwinds the Fabric mount transaction and takes the rest of the screen with it.
• The remaining non-finite framing values throw on neither side, but collapse the altitude to the map's minimum, or leave the camera and MKMapView.region reading back as NaN.

JS. An unusable camera is held at the last one the view accepted, with a __DEV__ warning. useValidCamera / resolveCameraProp mirror useValidRegion / resolveRegionProp, and isValidCamera reuses isValidCoordinate from utils/validateGeometry.ts.

Swift. Camera.isValid pairs Coordinate.isValid with a new CameraFraming, which lives in the Geometry SPM target so swift test covers it. Both adapters guard updateMapCamera, and the Google one also checks the camera its map is created with - that one never passes through updateMapCamera.

Kotlin. Camera.isValid() mirrors Region.isValid(), and the adapter checks before the main-thread hop, where a throw would surface as an uncaught main-looper exception no JS caller can catch.

hybridRef.setCamera and animateCamera funnel through the same guarded updateMapCamera, so JS validation alone was never enough.

Two things worth a reviewer's attention

A finite pitch outside 0..90 is clamped rather than treated as invalid, so an unsupported tilt no longer discards a usable center. MapKit flattens such a camera instead of refusing it, so this keeps the two platforms aligned; on Android drawableTilt coerces into the range CameraPosition accepts.

The prop must never go back to undefined - including when it is simply unset. React rewrites a removed prop to null (ReactNativeAttributePayload.js:271), the optional JSI converter short-circuits only on undefined (JSIConverter+Optional.hpp:26), and the generated struct converter then calls asObject on it: the #119 mechanism. This is the same correction #158 needed mid-review for region, and it applies identically here - camera={following ? camera : undefined} on a mounted view would otherwise throw - so resolveCameraProp holds the last accepted value on both transitions, invalid and unset.

Behavior change without a type change: an invalid camera used to crash the map and now updates nothing (with a __DEV__ warning); a pitch outside 0..90 used to crash on Android and is now clamped. No public type changed.

How was it verified?

Locally, on this branch rebased onto main at dbb904b:

The iOS build ran with betterMaps.iosGoogleProvider: "true" after a fresh pod install, so the #if canImport(GoogleMaps) half really compiled: GoogleMapProviderAdapter.o is 918 KB, alongside a fresh Camera+Validity.o and AppleMapProviderAdapter.o.

Test coverage added at all three levels: bun tests for isValidCamera and resolveCameraProp (including the unset transition), JUnit for Camera.isValid(), and swift-testing for CameraFraming. No simulator or device run - the crash paths themselves were reproduced earlier while writing the guards, not in this verification pass.

Scope

• Providers: both
• Platforms: both

Checklist

• bun run lint, bun run typecheck and bun run build pass
• Tests pass, and new behavior is covered by a test
• Nitro specs changed? bun run nitrogen was re-run - n/a, no spec change; camera?: Camera already existed
• Public API changed? The README and the capability matrix are updated - the "Invalid input" section now covers camera, and the two-gap note drops to one
• Commits follow Conventional Commits
• Behavior changed without a type change? Stated explicitly above

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}